home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc951.txt < prev    next >
Text File  |  1994-08-01  |  28KB  |  685 lines
  1.  
  2.  
  3. Network Working Group                   Bill Croft (Stanford University)
  4. Request for Comments: 951                John Gilmore (Sun Microsystems)
  5.                                                           September 1985
  6.  
  7.                        BOOTSTRAP PROTOCOL (BOOTP)
  8.  
  9.  
  10. 1. Status of this Memo
  11.  
  12.    This RFC suggests a proposed protocol for the ARPA-Internet
  13.    community, and requests discussion and suggestions for improvements.
  14.    Distribution of this memo is unlimited.
  15.  
  16. 2. Overview
  17.  
  18.    This RFC describes an IP/UDP bootstrap protocol (BOOTP) which allows
  19.    a diskless client machine to discover its own IP address, the address
  20.    of a server host, and the name of a file to be loaded into memory and
  21.    executed.  The bootstrap operation can be thought of as consisting of
  22.    TWO PHASES.  This RFC describes the first phase, which could be
  23.    labeled 'address determination and bootfile selection'.  After this
  24.    address and filename information is obtained, control passes to the
  25.    second phase of the bootstrap where a file transfer occurs.  The file
  26.    transfer will typically use the TFTP protocol [9], since it is
  27.    intended that both phases reside in PROM on the client.  However
  28.    BOOTP could also work with other protocols such as SFTP [3] or
  29.    FTP [6].
  30.  
  31.    We suggest that the client's PROM software provide a way to do a
  32.    complete bootstrap without 'user' interaction.  This is the type of
  33.    boot that would occur during an unattended power-up.  A mechanism
  34.    should be provided for the user to manually supply the necessary
  35.    address and filename information to bypass the BOOTP protocol and
  36.    enter the file transfer phase directly.  If non-volatile storage is
  37.    available, we suggest keeping default settings there and bypassing
  38.    the BOOTP protocol unless these settings cause the file transfer
  39.    phase to fail.  If the cached information fails, the bootstrap should
  40.    fall back to phase 1 and use BOOTP.
  41.  
  42.    Here is a brief outline of the protocol:
  43.  
  44.       1. A single packet exchange is performed.  Timeouts are used to
  45.       retransmit until a reply is received.  The same packet field
  46.       layout is used in both directions.  Fixed length fields of maximum
  47.       reasonable length are used to simplify structure definition and
  48.       parsing.
  49.  
  50.       2. An 'opcode' field exists with two values.  The client
  51.       broadcasts a 'bootrequest' packet.  The server then answers with a
  52.       'bootreply' packet.  The bootrequest contains the client's
  53.       hardware address and its IP address, if known.
  54.  
  55.  
  56. Croft & Gilmore                                                 [Page 1]
  57.  
  58.  
  59.  
  60. RFC 951                                                   September 1985
  61. Bootstrap Protocol
  62.  
  63.  
  64.       3. The request can optionally contain the name of the server the
  65.       client wishes to respond.  This is so the client can force the
  66.       boot to occur from a specific host (e.g. if multiple versions of
  67.       the same bootfile exist or if the server is in a far distant
  68.       net/domain).  The client does not have to deal with name / domain
  69.       services; instead this function is pushed off to the BOOTP server.
  70.  
  71.       4. The request can optionally contain the 'generic' filename to be
  72.       booted.  For example 'unix' or 'ethertip'.  When the server sends
  73.       the bootreply, it replaces this field with the fully qualified
  74.       path name of the appropriate boot file.  In determining this name,
  75.       the server may consult his own database correlating the client's
  76.       address and filename request, with a particular boot file
  77.       customized for that client.  If the bootrequest filename is a null
  78.       string, then the server returns a filename field indicating the
  79.       'default' file to be loaded for that client.
  80.  
  81.       5. In the case of clients who do not know their IP addresses, the
  82.       server must also have a database relating hardware address to IP
  83.       address.  This client IP address is then placed into a field in
  84.       the bootreply.
  85.  
  86.       6. Certain network topologies (such as Stanford's) may be such
  87.       that a given physical cable does not have a TFTP server directly
  88.       attached to it (e.g. all the gateways and hosts on a certain cable
  89.       may be diskless).  With the cooperation of neighboring gateways,
  90.       BOOTP can allow clients to boot off of servers several hops away,
  91.       through these gateways.  See the section 'Booting Through
  92.       Gateways' below.  This part of the protocol requires no special
  93.       action on the part of the client.  Implementation is optional and
  94.       requires a small amount of additional code in gateways and
  95.       servers.
  96.  
  97. 3. Packet Format
  98.  
  99.    All numbers shown are decimal, unless indicated otherwise.  The BOOTP
  100.    packet is enclosed in a standard IP [8] UDP [7] datagram.  For
  101.    simplicity it is assumed that the BOOTP packet is never fragmented.
  102.    Any numeric fields shown are packed in 'standard network byte order',
  103.    i.e. high order bits are sent first.
  104.  
  105.    In the IP header of a bootrequest, the client fills in its own IP
  106.    source address if known, otherwise zero.  When the server address is
  107.    unknown, the IP destination address will be the 'broadcast address'
  108.    255.255.255.255.  This address means 'broadcast on the local cable,
  109.    (I don't know my net number)' [4].
  110.  
  111.  
  112.  
  113. Croft & Gilmore                                                 [Page 2]
  114.  
  115.  
  116.  
  117. RFC 951                                                   September 1985
  118. Bootstrap Protocol
  119.  
  120.  
  121.    The UDP header contains source and destination port numbers.  The
  122.    BOOTP protocol uses two reserved port numbers, 'BOOTP client' (68)
  123.    and 'BOOTP server' (67).  The client sends requests using 'BOOTP
  124.    server' as the destination port; this is usually a broadcast.  The
  125.    server sends replies using 'BOOTP client' as the destination port;
  126.    depending on the kernel or driver facilities in the server, this may
  127.    or may not be a broadcast (this is explained further in the section
  128.    titled 'Chicken/Egg issues' below).  The reason TWO reserved ports
  129.    are used, is to avoid 'waking up' and scheduling the BOOTP server
  130.    daemons, when a bootreply must be broadcast to a client.  Since the
  131.    server and other hosts won't be listening on the 'BOOTP client' port,
  132.    any such incoming broadcasts will be filtered out at the kernel
  133.    level.  We could not simply allow the client to pick a 'random' port
  134.    number for the UDP source port field; since the server reply may be
  135.    broadcast, a randomly chosen port number could confuse other hosts
  136.    that happened to be listening on that port.
  137.  
  138.    The UDP length field is set to the length of the UDP plus BOOTP
  139.    portions of the packet.  The UDP checksum field can be set to zero by
  140.    the client (or server) if desired, to avoid this extra overhead in a
  141.    PROM implementation.  In the 'Packet Processing' section below the
  142.    phrase '[UDP checksum.]' is used whenever the checksum might be
  143.    verified/computed.
  144.  
  145.       FIELD   BYTES   DESCRIPTION
  146.       -----   -----   -----------
  147.  
  148.          op      1       packet op code / message type.
  149.                          1 = BOOTREQUEST, 2 = BOOTREPLY
  150.  
  151.          htype   1       hardware address type,
  152.                          see ARP section in "Assigned Numbers" RFC.
  153.                          '1' = 10mb ethernet
  154.  
  155.          hlen    1       hardware address length
  156.                          (eg '6' for 10mb ethernet).
  157.  
  158.          hops    1       client sets to zero,
  159.                          optionally used by gateways
  160.                          in cross-gateway booting.
  161.  
  162.          xid     4       transaction ID, a random number,
  163.                          used to match this boot request with the
  164.                          responses it generates.
  165.  
  166.          secs    2       filled in by client, seconds elapsed since
  167.                          client started trying to boot.
  168.  
  169.  
  170. Croft & Gilmore                                                 [Page 3]
  171.  
  172.  
  173.  
  174. RFC 951                                                   September 1985
  175. Bootstrap Protocol
  176.  
  177.  
  178.          --      2       unused
  179.  
  180.          ciaddr  4       client IP address;
  181.                          filled in by client in bootrequest if known.
  182.  
  183.          yiaddr  4       'your' (client) IP address;
  184.                          filled by server if client doesn't
  185.                          know its own address (ciaddr was 0).
  186.  
  187.          siaddr  4       server IP address;
  188.                          returned in bootreply by server.
  189.  
  190.          giaddr  4       gateway IP address,
  191.                          used in optional cross-gateway booting.
  192.  
  193.          chaddr  16      client hardware address,
  194.                          filled in by client.
  195.  
  196.          sname   64      optional server host name,
  197.                          null terminated string.
  198.  
  199.          file    128     boot file name, null terminated string;
  200.                          'generic' name or null in bootrequest,
  201.                          fully qualified directory-path
  202.                          name in bootreply.
  203.  
  204.          vend    64      optional vendor-specific area,
  205.                          e.g. could be hardware type/serial on request,
  206.                          or 'capability' / remote file system handle
  207.                          on reply.  This info may be set aside for use
  208.                          by a third phase bootstrap or kernel.
  209.  
  210. 4. Chicken / Egg Issues
  211.  
  212.    How can the server send an IP datagram to the client, if the client
  213.    doesnt know its own IP address (yet)?  Whenever a bootreply is being
  214.    sent, the transmitting machine performs the following operations:
  215.  
  216.       1. If the client knows its own IP address ('ciaddr' field is
  217.       nonzero), then the IP can be sent 'as normal', since the client
  218.       will respond to ARPs [5].
  219.  
  220.       2. If the client does not yet know its IP address (ciaddr zero),
  221.       then the client cannot respond to ARPs sent by the transmitter of
  222.       the bootreply.  There are two options:
  223.  
  224.          a. If the transmitter has the necessary kernel or driver hooks
  225.  
  226.  
  227. Croft & Gilmore                                                 [Page 4]
  228.  
  229.  
  230.  
  231. RFC 951                                                   September 1985
  232. Bootstrap Protocol
  233.  
  234.  
  235.          to 'manually' construct an ARP address cache entry, then it can
  236.          fill in an entry using the 'chaddr' and 'yiaddr' fields.  Of
  237.          course, this entry should have a timeout on it, just like any
  238.          other entry made by the normal ARP code itself.  The
  239.          transmitter of the bootreply can then simply send the bootreply
  240.          to the client's IP address.  UNIX (4.2 BSD) has this
  241.          capability.
  242.  
  243.          b. If the transmitter lacks these kernel hooks, it can simply
  244.          send the bootreply to the IP broadcast address on the
  245.          appropriate interface.  This is only one additional broadcast
  246.          over the previous case.
  247.  
  248. 5. Client Use of ARP
  249.  
  250.    The client PROM must contain a simple implementation of ARP, e.g. the
  251.    address cache could be just one entry in size.  This will allow a
  252.    second-phase-only boot (TFTP) to be performed when the client knows
  253.    the IP addresses and bootfile name.
  254.  
  255.    Any time the client is expecting to receive a TFTP or BOOTP reply, it
  256.    should be prepared to answer an ARP request for its own IP to
  257.    hardware address mapping (if known).
  258.  
  259.    Since the bootreply will contain (in the hardware encapsulation) the
  260.    hardware source address of the server/gateway, the client MAY be able
  261.    to avoid sending an ARP request for the server/gateway IP address to
  262.    be used in the following TFTP phase.  However this should be treated
  263.    only as a special case, since it is desirable to still allow a
  264.    second-phase-only boot as described above.
  265.  
  266. 6. Comparison to RARP
  267.  
  268.    An earlier protocol, Reverse Address Resolution Protocol (RARP) [1]
  269.    was proposed to allow a client to determine its IP address, given
  270.    that it knew its hardware address.  However RARP had the disadvantage
  271.    that it was a hardware link level protocol (not IP/UDP based).  This
  272.    means that RARP could only be implemented on hosts containing special
  273.    kernel or driver modifications to access these 'raw' packets.  Since
  274.    there are many network kernels existent now, with each source
  275.    maintained by different organizations, a boot protocol that does not
  276.    require kernel modifications is a decided advantage.
  277.  
  278.    BOOTP provides this hardware to IP address lookup function, in
  279.    addition to the other useful features described in the sections
  280.    above.
  281.  
  282.  
  283.  
  284. Croft & Gilmore                                                 [Page 5]
  285.  
  286.  
  287.  
  288. RFC 951                                                   September 1985
  289. Bootstrap Protocol
  290.  
  291.  
  292. 7. Packet Processing
  293.  
  294.    7.1. Client Transmission
  295.  
  296.       Before setting up the packet for the first time, it is a good idea
  297.       to clear the entire packet buffer to all zeros; this will place
  298.       all fields in their default state.  The client then creates a
  299.       packet with the following fields.
  300.  
  301.       The IP destination address is set to 255.255.255.255.  (the
  302.       broadcast address) or to the server's IP address (if known).  The
  303.       IP source address and 'ciaddr' are set to the client's IP address
  304.       if known, else 0.  The UDP header is set with the proper length;
  305.       source port = 'BOOTP client' port destination port = 'BOOTP
  306.       server' port.
  307.  
  308.       'op' is set to '1', BOOTREQUEST.  'htype' is set to the hardware
  309.       address type as assigned in the ARP section of the "Assigned
  310.       Numbers" RFC. 'hlen' is set to the length of the hardware address,
  311.       e.g. '6' for 10mb ethernet.
  312.  
  313.       'xid' is set to a 'random' transaction id.  'secs' is set to the
  314.       number of seconds that have elapsed since the client has started
  315.       booting.  This will let the servers know how long a client has
  316.       been trying.  As the number gets larger, certain servers may feel
  317.       more 'sympathetic' towards a client they don't normally service.
  318.       If a client lacks a suitable clock, it could construct a rough
  319.       estimate using a loop timer.  Or it could choose to simply send
  320.       this field as always a fixed value, say 100 seconds.
  321.  
  322.       If the client knows its IP address, 'ciaddr' (and the IP source
  323.       address) are set to this value.  'chaddr' is filled in with the
  324.       client's hardware address.
  325.  
  326.       If the client wishes to restrict booting to a particular server
  327.       name, it may place a null-terminated string in 'sname'.  The name
  328.       used should be any of the allowable names or nicknames of the
  329.       desired host.
  330.  
  331.       The client has several options for filling the 'file' name field.
  332.       If left null, the meaning is 'I want to boot the default file for
  333.       my machine'.  A null file name can also mean 'I am only interested
  334.       in finding out client/server/gateway IP addresses, I dont care
  335.       about file names'.
  336.  
  337.       The field can also be a 'generic' name such as 'unix' or
  338.  
  339.  
  340.  
  341. Croft & Gilmore                                                 [Page 6]
  342.  
  343.  
  344.  
  345. RFC 951                                                   September 1985
  346. Bootstrap Protocol
  347.  
  348.  
  349.       'gateway'; this means 'boot the named program configured for my
  350.       machine'.  Finally the field can be a fully directory qualified
  351.       path name.
  352.  
  353.       The 'vend' field can be filled in by the client with
  354.       vendor-specific strings or structures.  For example the machine
  355.       hardware type or serial number may be placed here.  However the
  356.       operation of the BOOTP server should not DEPEND on this
  357.       information existing.
  358.  
  359.       If the 'vend' field is used, it is recommended that a 4 byte
  360.       'magic number' be the first item within 'vend'.  This lets a
  361.       server determine what kind of information it is seeing in this
  362.       field.  Numbers can be assigned by the usual 'magic number'
  363.       process --you pick one and it's magic.  A different magic number
  364.       could be used for bootreply's than bootrequest's to allow the
  365.       client to take special action with the reply information.
  366.  
  367.       [UDP checksum.]
  368.  
  369.    7.2. Client Retransmission Strategy
  370.  
  371.       If no reply is received for a certain length of time, the client
  372.       should retransmit the request.  The time interval must be chosen
  373.       carefully so as not to flood the network.  Consider the case of a
  374.       cable containing 100 machines that are just coming up after a
  375.       power failure.  Simply retransmitting the request every four
  376.       seconds will inundate the net.
  377.  
  378.       As a possible strategy, you might consider backing off
  379.       exponentially, similar to the way ethernet backs off on a
  380.       collision.  So for example if the first packet is at time 0:00,
  381.       the second would be at :04, then :08, then :16, then :32, then
  382.       :64.  You should also randomize each time; this would be done
  383.       similar to the ethernet specification by starting with a mask and
  384.       'and'ing that with with a random number to get the first backoff.
  385.       On each succeeding backoff, the mask is increased in length by one
  386.       bit.  This doubles the average delay on each backoff.
  387.  
  388.       After the 'average' backoff reaches about 60 seconds, it should be
  389.       increased no further, but still randomized.
  390.  
  391.       Before each retransmission, the client should update the 'secs'
  392.       field. [UDP checksum.]
  393.  
  394.  
  395.  
  396.  
  397.  
  398. Croft & Gilmore                                                 [Page 7]
  399.  
  400.  
  401.  
  402. RFC 951                                                   September 1985
  403. Bootstrap Protocol
  404.  
  405.  
  406.    7.3. Server Receives BOOTREQUEST
  407.  
  408.       [UDP checksum.]  If the UDP destination port does not match the
  409.       'BOOTP server' port, discard the packet.
  410.  
  411.       If the server name field (sname) is null (no particular server
  412.       specified), or sname is specified and matches our name or
  413.       nickname, then continue with packet processing.
  414.  
  415.       If the sname field is specified, but does not match 'us', then
  416.       there are several options:
  417.  
  418.          1. You may choose to simply discard this packet.
  419.  
  420.          2. If a name lookup on sname shows it to be on this same cable,
  421.          discard the packet.
  422.  
  423.          3. If sname is on a different net, you may choose to forward
  424.          the packet to that address.  If so, check the 'giaddr' (gateway
  425.          address) field.  If 'giaddr' is zero, fill it in with my
  426.          address or the address of a gateway that can be used to get to
  427.          that net.  Then forward the packet.
  428.  
  429.       If the client IP address (ciaddr) is zero, then the client does
  430.       not know its own IP address.  Attempt to lookup the client
  431.       hardware address (chaddr, hlen, htype) in our database.  If no
  432.       match is found, discard the packet.  Otherwise we now have an IP
  433.       address for this client; fill it into the 'yiaddr' (your IP
  434.       address) field.
  435.  
  436.       We now check the boot file name field (file).  The field will be
  437.       null if the client is not interested in filenames, or wants the
  438.       default bootfile.  If the field is non-null, it is used as a
  439.       lookup key in a database, along with the client's IP address.  If
  440.       there is a default file or generic file (possibly indexed by the
  441.       client address) or a fully-specified path name that matches, then
  442.       replace the 'file' field with the fully-specified path name of the
  443.       selected boot file.  If the field is non-null and no match was
  444.       found, then the client is asking for a file we dont have; discard
  445.       the packet, perhaps some other BOOTP server will have it.
  446.  
  447.       The 'vend' vendor-specific data field should now be checked and if
  448.       a recognized type of data is provided, client-specific actions
  449.       should be taken, and a response placed in the 'vend' data field of
  450.       the reply packet.  For example, a workstation client could provide
  451.  
  452.  
  453.  
  454.  
  455. Croft & Gilmore                                                 [Page 8]
  456.  
  457.  
  458.  
  459. RFC 951                                                   September 1985
  460. Bootstrap Protocol
  461.  
  462.  
  463.       an authentication key and receive from the server a capability for
  464.       remote file access, or a set of configuration options, which can
  465.       be passed to the operating system that will shortly be booted in.
  466.  
  467.       Place my (server) IP address in the 'siaddr' field.  Set the 'op'
  468.       field to BOOTREPLY.  The UDP destination port is set to 'BOOTP
  469.       client'.  If the client address 'ciaddr' is nonzero, send the
  470.       packet there; else if the gateway address 'giaddr' is nonzero, set
  471.       the UDP destination port to 'BOOTP server' and send the packet to
  472.       'giaddr'; else the client is on one of our cables but it doesnt
  473.       know its own IP address yet --use a method described in the 'Egg'
  474.       section above to send it to the client. If 'Egg' is used and we
  475.       have multiple interfaces on this host, use the 'yiaddr' (your IP
  476.       address) field to figure out which net (cable/interface) to send
  477.       the packet to.  [UDP checksum.]
  478.  
  479.    7.4. Server/Gateway Receives BOOTREPLY
  480.  
  481.       [UDP checksum.]  If 'yiaddr' (your [the client's] IP address)
  482.       refers to one of our cables, use one of the 'Egg' methods above to
  483.       forward it to the client.  Be sure to send it to the 'BOOTP
  484.       client' UDP destination port.
  485.  
  486.    7.5. Client Reception
  487.  
  488.       Don't forget to process ARP requests for my own IP address (if I
  489.       know it).  [UDP checksum.]  The client should discard incoming
  490.       packets that: are not IP/UDPs addressed to the boot port; are not
  491.       BOOTREPLYs; do not match my IP address (if I know it) or my
  492.       hardware address; do not match my transaction id.  Otherwise we
  493.       have received a successful reply. 'yiaddr' will contain my IP
  494.       address, if I didnt know it before.  'file' is the name of the
  495.       file name to TFTP 'read request'.  The server address is in
  496.       'siaddr'.  If 'giaddr' (gateway address) is nonzero, then the
  497.       packets should be forwarded there first, in order to get to the
  498.       server.
  499.  
  500. 8. Booting Through Gateways
  501.  
  502.    This part of the protocol is optional and requires some additional
  503.    code in cooperating gateways and servers, but it allows cross-gateway
  504.    booting.  This is mainly useful when gateways are diskless machines.
  505.    Gateways containing disks (e.g. a UNIX machine acting as a gateway),
  506.    might as well run their own BOOTP/TFTP servers.
  507.  
  508.    Gateways listening to broadcast BOOTREQUESTs may decide to forward or
  509.    rebroadcast these requests 'when appropriate'.  For example, the
  510.  
  511.  
  512. Croft & Gilmore                                                 [Page 9]
  513.  
  514.  
  515.  
  516. RFC 951                                                   September 1985
  517. Bootstrap Protocol
  518.  
  519.  
  520.    gateway could have, as part of his configuration tables, a list of
  521.    other networks or hosts to receive a copy of any broadcast
  522.    BOOTREQUESTs.  Even though a 'hops' field exists, it is a poor idea
  523.    to simply globally rebroadcast the requests, since broadcast loops
  524.    will almost certainly occur.
  525.  
  526.    The forwarding could begin immediately, or wait until the 'secs'
  527.    (seconds client has been trying) field passes a certain threshold.
  528.  
  529.    If a gateway does decide to forward the request, it should look at
  530.    the 'giaddr' (gateway IP address) field.  If zero, it should plug its
  531.    own IP address (on the receiving cable) into this field.  It may also
  532.    use the 'hops' field to optionally control how far the packet is
  533.    reforwarded. Hops should be incremented on each forwarding.  For
  534.    example, if hops passes '3', the packet should probably be discarded.
  535.    [UDP checksum.]
  536.  
  537.    Here we have recommended placing this special forwarding function in
  538.    the gateways.  But that does not have to be the case.  As long as
  539.    some 'BOOTP forwarding agent' exists on the net with the booting
  540.    client, the agent can do the forwarding when appropriate.  Thus this
  541.    service may or may not be co-located with the gateway.
  542.  
  543.    In the case of a forwarding agent not located in the gateway, the
  544.    agent could save himself some work by plugging the broadcast address
  545.    of the interface receiving the bootrequest into the 'giaddr' field.
  546.    Thus the reply would get forwarded using normal gateways, not
  547.    involving the forwarding agent.  Of course the disadvantage here is
  548.    that you lose the ability to use the 'Egg' non-broadcast method of
  549.    sending the reply, causing extra overhead for every host on the
  550.    client cable.
  551.  
  552. 9. Sample BOOTP Server Database
  553.  
  554.    As a suggestion, we show a sample text file database that the BOOTP
  555.    server program might use.  The database has two sections, delimited
  556.    by a line containing an percent in column 1.  The first section
  557.    contains a 'default directory' and mappings from generic names to
  558.    directory/pathnames.  The first generic name in this section is the
  559.    'default file' you get when the bootrequest contains a null 'file'
  560.    string.
  561.  
  562.    The second section maps hardware addresstype/address into an
  563.    ipaddress. Optionally you can also overide the default generic name
  564.    by supplying a ipaddress specific genericname.  A 'suffix' item is
  565.    also an option; if supplied, any generic names specified by the
  566.    client will be accessed by first appending 'suffix' to the 'pathname'
  567.  
  568.  
  569. Croft & Gilmore                                                [Page 10]
  570.  
  571.  
  572.  
  573. RFC 951                                                   September 1985
  574. Bootstrap Protocol
  575.  
  576.  
  577.    appropriate to that generic name.  If that file is not found, then
  578.    the plain 'pathname' will be tried.  This 'suffix' option allows a
  579.    whole set of custom generics to be setup without a lot of effort.
  580.    Below is shown the general format; fields are delimited by one or
  581.    more spaces or tabs; trailing empty fields may be omitted; blank
  582.    lines and lines beginning with '#' are ignored.
  583.  
  584.       # comment line
  585.  
  586.       homedirectory
  587.       genericname1    pathname1
  588.       genericname2    pathname2
  589.       ...
  590.  
  591.       % end of generic names, start of address mappings
  592.  
  593.       hostname1 hardwaretype hardwareaddr1 ipaddr1 genericname suffix
  594.       hostname2 hardwaretype hardwareaddr2 ipaddr2 genericname suffix
  595.       ...
  596.  
  597.    Here is a specific example.  Note the 'hardwaretype' number is the
  598.    same as that shown in the ARP section of the 'Assigned Numbers' RFC.
  599.    The 'hardwaretype' and 'ipaddr' numbers are in decimal;
  600.    'hardwareaddr' is in hex.
  601.  
  602.       # last updated by smith
  603.  
  604.       /usr/boot
  605.       vmunix          vmunix
  606.       tip             ethertip
  607.       watch           /usr/diag/etherwatch
  608.       gate            gate.
  609.  
  610.       % end of generic names, start of address mappings
  611.  
  612.       hamilton        1 02.60.8c.06.34.98     36.19.0.5
  613.       burr            1 02.60.8c.34.11.78     36.44.0.12
  614.       101-gateway     1 02.60.8c.23.ab.35     36.44.0.32      gate 101
  615.       mjh-gateway     1 02.60.8c.12.32.bc     36.42.0.64      gate mjh
  616.       welch-tipa      1 02.60.8c.22.65.32     36.47.0.14      tip
  617.       welch-tipb      1 02.60.8c.12.15.c8     36.46.0.12      tip
  618.  
  619.    In the example above, if 'mjh-gateway' does a default boot, it will
  620.    get the file '/usr/boot/gate.mjh'.
  621.  
  622.  
  623.  
  624.  
  625.  
  626. Croft & Gilmore                                                [Page 11]
  627.  
  628.  
  629.  
  630. RFC 951                                                   September 1985
  631. Bootstrap Protocol
  632.  
  633.  
  634. 10. Acknowledgements
  635.  
  636.    Ross Finlayson (et. al.) produced two earlier RFC's discussing TFTP
  637.    bootstraping [2] using RARP [1].
  638.  
  639.    We would also like to acknowledge the previous work and comments of
  640.    Noel Chiappa, Bob Lyon, Jeff Mogul, Mark Lewis, and David Plummer.
  641.  
  642. REFERENCES
  643.  
  644.    1.  Ross Finlayson, Timothy Mann, Jeffrey Mogul, Marvin Theimer.  A
  645.        Reverse Address Resolution Protocol.  RFC 903, NIC, June, 1984.
  646.  
  647.    2.  Ross Finlayson.  Bootstrap Loading using TFTP.  RFC 906, NIC,
  648.        June, 1984.
  649.  
  650.    3.  Mark Lottor.  Simple File Transfer Protocol.  RFC 913, NIC,
  651.        September, 1984.
  652.  
  653.    4.  Jeffrey Mogul.  Broadcasting Internet Packets.  RFC 919, NIC,
  654.        October, 1984.
  655.  
  656.    5.  David Plummer.  An Ethernet Address Resolution Protocol.  RFC
  657.        826, NIC, September, 1982.
  658.  
  659.    6.  Jon Postel.  File Transfer Protocol.  RFC 765, NIC, June, 1980.
  660.  
  661.    7.  Jon Postel.  User Datagram Protocol.  RFC 768, NIC, August, 1980.
  662.  
  663.    8.  Jon Postel.  Internet Protocol.  RFC 791, NIC, September, 1981.
  664.  
  665.    9.  K. R. Sollins, Noel Chiappa.  The TFTP Protocol.  RFC 783, NIC,
  666.        June, 1981.
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.  
  683. Croft & Gilmore                                                [Page 12]
  684.  
  685.